home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-822ext-iso2022jp-02.txt < prev    next >
Encoding:
Text File  |  1993-03-03  |  10.9 KB  |  335 lines
  1.  
  2. Network Working Group                                          Jun Murai
  3. Internet Draft                                              Mark Crispin
  4.                                                        Erik van der Poel
  5.                                                        1st December 1992
  6.  
  7.  
  8.         Japanese Character Encoding for Internet Message Bodies
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This document is an Internet Draft.  Internet Drafts are working
  14.    documents of the Internet Engineering Task Force (IETF), its Areas,
  15.    and its Working Groups. Note that other groups may also distribute
  16.    working documents as Internet Drafts.
  17.  
  18.    Internet Drafts are draft documents valid for a maximum of six
  19.    months. Internet Drafts may be updated, replaced, or obsoleted by
  20.    other documents at any time.  It is not appropriate to use Internet
  21.    Drafts as reference material or to cite them other than as a "working
  22.    draft" or "work in progress."
  23.  
  24.    Please check the I-D abstract listing contained in each Internet
  25.    Draft directory to learn the current status of this or any other
  26.    Internet Draft.
  27.  
  28.    This draft document will be submitted to the RFC editor as an
  29.    informational document.  This document will expire before 1st June
  30.    1993.  Distribution of this memo is unlimited.  Please send comments
  31.    to ietf-822@dimacs.rutgers.edu.
  32.  
  33.  
  34. Introduction
  35.  
  36.    This document describes the encoding used in electronic mail [RFC822]
  37.    and network news [RFC1036] message bodies in several Japanese
  38.    networks. It was first specified by and used in JUNET [JUNET]. The
  39.    encoding is now also widely used in Japanese IP communities.
  40.  
  41.    This document names the encoding "ISO-2022-JP", which is intended to
  42.    be used in the "charset" parameter field of MIME [MIME] messages. The
  43.    use of ISO-2022-JP in RFC 1342 [RFC1342] headers is expected to be
  44.    the subject of a separate document.
  45.  
  46.    This document only describes the encoding of plain text. The encoding
  47.    of other subtypes of text, such as richtext, is not discussed here.
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Murai et al              Expires 1st June 1993                  [Page 1]
  54.  
  55. Internet Draft                                 Updated 1st December 1992
  56.  
  57.  
  58. Description
  59.  
  60.    The message body starts in ASCII [ASCII], and switches to Japanese
  61.    characters through an escape sequence. For example, the escape
  62.    sequence ESC $ B (three bytes, hexadecimal values: 1B 24 42)
  63.    indicates that the bytes following this escape sequence are Japanese
  64.    characters, which are encoded in two bytes each.  To switch back to
  65.    ASCII, the escape sequence ESC ( B is used.
  66.  
  67.    The following table gives the escape sequences and the character sets
  68.    used in ISO-2022-JP messages. The ISOREG number is the registration
  69.    number in ISO's registry [ISOREG].
  70.  
  71.        Esc Seq    Character Set                  ISOREG
  72.  
  73.        ESC ( B    ASCII                             6
  74.        ESC ( J    JIS X 0201-1976 ("Roman" set)    14
  75.        ESC $ @    JIS X 0208-1978                  42
  76.        ESC $ B    JIS X 0208-1983                  87
  77.  
  78.    Note that JIS X 0208-1983 was called JIS C 6226-1983 until the name
  79.    was changed in March 1987. Likewise, JIS C 6220 was renamed JIS X
  80.    0201.
  81.  
  82.    The "Roman" character set of JIS X 0201 [JISX0201] is identical to
  83.    ASCII except for backslash (\) and tilde (~). The backslash is
  84.    replaced by the Yen sign, and the tilde is replaced by macron
  85.    (overline). This set is Japan's national variant of ISO 646 [ISO646].
  86.  
  87.    The JIS X 0208 [JISX0208] character sets consist of Kanji, Hiragana,
  88.    Katakana and some other symbols and characters. Each character takes
  89.    up two bytes.
  90.  
  91.    For further details about the JIS Japanese national character set
  92.    standards, refer to [JISX0201] and [JISX0208].  For further
  93.    information about the escape sequences, see [ISO2022] and [ISOREG].
  94.  
  95.    If there are JIS X 0208 characters on a line, there must be a switch
  96.    to ASCII or to the "Roman" set of JIS X 0201 before the end of the
  97.    line (i.e. before the CRLF). This means that the next line starts in
  98.    the character set that was switched to before the end of the previous
  99.    line.
  100.  
  101.    Also, the message body must end with CRLF, and there must be a switch
  102.    to ASCII before the last CRLF (if there are any non-ASCII characters
  103.    in the message body).
  104.  
  105.    Other restrictions are given in the Formal Syntax below.
  106.  
  107.  
  108.  
  109. Murai et al              Expires 1st June 1993                  [Page 2]
  110.  
  111. Internet Draft                                 Updated 1st December 1992
  112.  
  113.  
  114. Formal Syntax
  115.  
  116.    The notational conventions used here are identical to those used in
  117.    RFC 822 [RFC822].
  118.  
  119.    The * (asterisk) convention is as follows:
  120.  
  121.            l*m something
  122.  
  123.    meaning at least l and at most m somethings, with l and m taking
  124.    default values of 0 and infinity, respectively.
  125.  
  126.  
  127.    line                = *text *1( *segment single-byte-seq *text ) CRLF
  128.  
  129.    segment             = single-byte-segment / double-byte-segment
  130.  
  131.    single-byte-segment = single-byte-seq 1*text
  132.  
  133.    double-byte-segment = double-byte-seq 1*( one-of-94 one-of-94 )
  134.  
  135.    single-byte-seq     = ESC "(" ( "B" / "J" )
  136.  
  137.    double-byte-seq     = ESC "$" ( "@" / "B" )
  138.  
  139.                                                     ; ( Octal, Decimal.)
  140.  
  141.    ESC                 = <ISO 2022 ESC, escape>     ; (    33,      27.)
  142.  
  143.    SI                  = <ISO 2022 SI, shift-in>    ; (    17,      15.)
  144.  
  145.    SO                  = <ISO 2022 SO, shift-out>   ; (    16,      14.)
  146.  
  147.    one-of-94           = <any char in 94-char set>  ; (41-176, 33.-126.)
  148.  
  149.    CHAR                = <any ASCII character>      ; ( 0-177,  0.-127.)
  150.  
  151.    text                = <any CHAR, including bare CR & bare LF, but NOT
  152.                           including CRLF, and not including ESC, SI, SO>
  153.  
  154.  
  155. MIME Considerations
  156.  
  157.    The name given to the JUNET character encoding is "ISO-2022-JP". This
  158.    name is intended to be used in MIME messages as follows:
  159.  
  160.            Content-Type: text/plain; charset=iso-2022-jp
  161.  
  162.  
  163.  
  164.  
  165. Murai et al              Expires 1st June 1993                  [Page 3]
  166.  
  167. Internet Draft                                 Updated 1st December 1992
  168.  
  169.  
  170.    The ISO-2022-JP encoding is already in 7-bit form, so it is not
  171.    necessary to use a Content-Transfer-Encoding header. It should be
  172.    noted that applying the Base64 or Quoted-Printable encoding will
  173.    render the message unreadable in current JUNET software.
  174.  
  175.  
  176. Background Information
  177.  
  178.    The JUNET encoding was described in the JUNET User's Guide [JUNET]
  179.    (JUNET Riyou No Tebiki Dai Ippan).
  180.  
  181.    The encoding is based on the particular usage of ISO 2022 announced
  182.    by 4/1 (see [ISO2022] for details). However, the escape sequence
  183.    normally used for this announcement is not included in ISO-2022-JP
  184.    messages.
  185.  
  186.    The so-called half-width (hankaku) Katakana, that is, the Kana set of
  187.    JIS X 0201, are not used in ISO-2022-JP messages.
  188.  
  189.    In the past, some systems erroneously used the escape sequence ESC (
  190.    H in JUNET messages. This escape sequence is officially registered
  191.    for a Swedish character set [ISOREG], and should not be used in ISO-
  192.    2022-JP messages.
  193.  
  194.    Some systems do not distinguish between ESC ( B and ESC ( J or
  195.    between ESC $ @ and ESC $ B for display. However, when relaying a
  196.    message to another system, the escape sequences must not be altered
  197.    in any way.
  198.  
  199.    The human user (not implementor) should try to keep lines within 80
  200.    display columns, or, preferably, within 75 (or so) columns, to allow
  201.    insertion of ">" at the beginning of each line in excerpts. Each JIS
  202.    X 0208 character takes up two columns, and the escape sequences do
  203.    not take up any columns. The implementor is reminded that JIS X 0208
  204.    characters take up two bytes and should not be split in the middle to
  205.    break lines for displaying, etc.
  206.  
  207.    The JIS X 0208 standard was revised in 1990, to add two characters at
  208.    the end of the table. Although ISO 2022 specifies special additional
  209.    escape sequences to indicate the use of revised character sets, it is
  210.    suggested here not to make use of this special escape sequence in
  211.    ISO-2022-JP text, even if the two characters added to JIS X 0208 in
  212.    1990 are used.
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Murai et al              Expires 1st June 1993                  [Page 4]
  222.  
  223. Internet Draft                                 Updated 1st December 1992
  224.  
  225.  
  226. References
  227.  
  228.    [ASCII] American National Standards Institute, "Coded character set
  229.    -- 7-bit American national standard code for information
  230.    interchange", ANSI X3.4-1968
  231.  
  232.    [ISO646] International Organization for Standardization (ISO),
  233.    "Information processing -- ISO 7-bit coded character set for
  234.    information interchange", International Standard, Ref. No. ISO 646-
  235.    1983 (E)
  236.  
  237.    [ISO2022] International Organization for Standardization (ISO),
  238.    "Information processing -- ISO 7-bit and 8-bit coded character sets
  239.    -- Code extension techniques", International Standard, Ref. No. ISO
  240.    2022-1986 (E)
  241.  
  242.    [ISOREG] International Organization for Standardization (ISO),
  243.    "International Register of Coded Character Sets To Be Used With
  244.    Escape Sequences"
  245.  
  246.    [JISX0201] Japanese Standards Association, "Code for Information
  247.    Interchange", JIS X 0201-1976
  248.  
  249.    [JISX0208] Japanese Standards Association, "Code of the Japanese
  250.    graphic character set for information interchange", JIS X 0208-1978,
  251.    -1983 and -1990
  252.  
  253.    [JUNET] JUNET Riyou No Tebiki Sakusei Iin Kai (JUNET User's Guide
  254.    Drafting Committee), "JUNET Riyou No Tebiki (Dai Ippan)" ("JUNET
  255.    User's Guide (First Edition)"), February 1988
  256.  
  257.    [MIME] Nathaniel Borenstein and Ned Freed, "MIME (Multipurpose
  258.    Internet Mail Extensions): Mechanisms for Specifying and Describing
  259.    the Format of Internet Message Bodies", Proposed (Internet) standard,
  260.    June 1992, rfc1341
  261.  
  262.    [RFC822] David H. Crocker, "Standard for the Format of ARPA Internet
  263.    Text Messages", Internet standard, August 1982, rfc822
  264.  
  265.    [RFC1036] M. Horton and R. Adams, "Standard for Interchange of USENET
  266.    Messages", December 1987, rfc1036
  267.  
  268.    [RFC1342] Keith Moore, "Representation of Non-ASCII Text in Internet
  269.    Message Headers", Proposed (Internet) standard, June 1992, rfc1342
  270.  
  271.  
  272. Security Considerations
  273.  
  274.  
  275.  
  276.  
  277. Murai et al              Expires 1st June 1993                  [Page 5]
  278.  
  279. Internet Draft                                 Updated 1st December 1992
  280.  
  281.  
  282.    Security considerations are not discussed in this memo.
  283.  
  284.  
  285. Acknowledgements
  286.  
  287.    Many people assisted in drafting this document. The authors wish to
  288.    thank in particular Akira Kato, Masahiro Sekiguchi and Ken'ichi
  289.    Handa.
  290.  
  291.  
  292. Authors' Addresses
  293.  
  294.  
  295.    Jun Murai
  296.    Keio University
  297.    5322 Endo, Fujisawa
  298.    Kanagawa 252 Japan
  299.  
  300.    Fax: +81 (466) 49-1101
  301.  
  302.    EMail: jun@wide.ad.jp
  303.  
  304.  
  305.    Mark Crispin
  306.    Panda Programming
  307.    6158 Lariat Loop NE
  308.    Bainbridge Island, WA 98110-2098
  309.    USA
  310.  
  311.    Phone: +1 (206) 842-2385
  312.  
  313.    EMail: MRC@PANDA.COM
  314.  
  315.  
  316.    Erik M. van der Poel
  317.    A-105 Park Avenue
  318.    4-4-10 Ohta, Kisarazu
  319.    Chiba 292 Japan
  320.  
  321.    Phone: +81 (438) 22-5836
  322.    Fax:   +81 (438) 22-5837
  323.  
  324.    EMail: erik@poel.juice.or.jp
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Murai et al              Expires 1st June 1993                  [Page 6]
  334.  
  335.